1. Field of the Invention
This invention is related to the field of backup and restore of computer systems.
2. Description of the Related Art
Making comprehensive backups of computer system data is an integral part of safeguarding the data against a variety of failure events. Failure events may include a variety of failures, such as hardware failure leading to loss or corruption of the data, software failure leading to loss or corruption of the data, intentional destruction or corruption of data by malicious software such as viruses, environmental events such as electrical power failure, fire, etc. Periodically and reliably backing up the computer system data may thus be critical to the ability to recover from various failure events. Computer system data may comprise a set of files which store the instructions executed by the computer system (e.g. various application programs, operating system software, etc.) as well as related data such as configuration data and the data operated upon by the instructions during execution. Application programs will be more briefly referred to as applications, and operating system software will be more briefly referred to as the operating system or OS.
Some computer system data may be readily backed up. For example, some applications may be stopped, at least temporarily, to permit backup. Since the application is stopped, the files storing the application and the files used by the application are “closed” and thus the state of the files on the storage subsystem of the computer system is consistent and available for copying in the backup operation. However, other computer system data is more problematic. The backup software that performs the backup operation generally executes on the OS, and thus the OS is running during the backup operation. The OS may have at least some files “open” at the time the backup operation occurs. Additionally, for some applications, the performance loss incurred by stopping the application for backup and restarting the application is too large to be acceptable. Such applications remain in operation during backup operation, and may have various files open. A file is “closed” if no software is currently accessing (or able to access) the file. Thus, a closed file has a consistent state in the storage subsystem (e.g. on one or more volumes on one or more disk drives). A file is “open” if software is currently accessing the file or is able to access the file contents using a “handle” assigned to the file by the operating system when the software first accessed the file. An open file may have at least a portion of the file contents copied to memory, and updates to the file may be stored in memory as well (i.e. not yet committed to disk).
In the past, backup software implemented various open file managers to attempt to gather a consistent state of open files for backup. Open file management is complex. For example, gathering a consistent state for multiple files corresponding to a running application is difficult, as one file may be changed before the state is gathered and a corresponding change to another file may occur after the state is gathered. Additionally, as new features are added to the OS and/or applications, the mechanisms for gathering consistent state (and the identification of open files) may change. Thus, the open file managers are subject to frequent update.
Some OSs provide a mechanism to aid the backup process. For example, some OSs implement a service to provide consistent file state for backup. If the OS adds new features (typically creating new files), the service is changed to properly capture the file state for the new features. Backup software interacts with the service to capture the state of open files. Various versions of the Windows® operating system from Microsoft Corporation (Redmond, Wash.) implement such a service, named the Volume Shadow Copy Service (VSS). For example, Microsoft Windows Server™ 2003 and Windows XP implement VSS, and future releases are expected to implement VSS as well.
FIG. 1 is a block diagram illustrating the Volume Shadow Copy Service (VSS) 10 and various other computer system components that interact with the VSS 10. For example, one or more writers 12 are shown. The writers 12 are part of applications or operating system services that are designed to interact with the VSS 10. A requestor 14 is also shown. The requestor 14 interacts with the VSS 10 to obtain consistent sets of file data corresponding to the writers 12, shadow copies of volumes in a consistent state for backup, etc. Additionally, a set of providers 16A-16C are shown. The providers 16A-16C create and maintain volumes and shadow copies of volumes on the storage devices (e.g. disk drives) in the computer system. For example, volumes 18A-18C are shown corresponding to the providers 16A-16C, respectively. The system provider 16A is a default provider that is used if other providers are not included. The hardware provider 16B is part of the storage system hardware and is designed to create shadow copies in response to requests from the VSS 10. The software provider 16C is part of the OS or another application that provides the shadow copy functionality. One or more of any of the providers 16A-16C are included in a given system. The arrows between the VSS 10, the writers 12, the requestor 14, and the providers 16A-16C generally represent application program interfaces (APIs) used to communicate therebetween.
A backup operation generally includes the requestor 14 requesting that the VSS 10 enumerate the writers 12 and prepare for shadow copy creation. The writers 12 respond to the VSS 10 by describing the files that are to be backed up and also by describing the method to be used for restoring the files. In some cases, the files are not directly written back to their original location. For example, some files are placed in a temporary location, and a registry entry is created to restore the file to its proper location on reboot. The description of the files and/or restore methods is provided to the requestor 14 (e.g. as an extensible markup language (XML) document). The files are grouped into groups that are to be backed up as a unit. Each group of files identified by a writer 12 is referred to as a “shadow copy component”. The writers 12 prepare their shadow copy components for backup (e.g. flushing writes from memory to disk, completing open transactions, rolling transaction logs, flushing caches, etc.). The VSS 10 requests that the writers 12 quiesce briefly while a shadow copy is created, and freezes the file system. The VSS 10 then requests that the providers 16A-16C make a shadow copy of the volumes, and then permits the writers 12 to continue operation with the original volume copy. The requestor 14 then makes a backup from the shadow copy.
During a subsequent restore of a backup copy, the backup program follows the restore description in the XML document provided from the VSS 10 during the backup operation for the shadow copy components. While such a restore is performed when the backup program is executing in the client that was backed up, other types of backup/restore mechanisms may not perform the restore in this fashion. For example, the Bare Metal Restore™ (BMR) product from VERITAS™ Software Corporation (Mountain View, Calif.) is designed to restore a client to a different computer system from the one on which the backup was performed (or on the same computer system, but prior to installation of the client's OS). For clients running the Windows® OS, BMR executes on the computer system to which the restore is performed, in a restore environment used for the restore only. The client's computer system data is restored to a client environment. After the restore is complete, BMR updates the boot configuration to boot the client environment and reboots the computer system. After the reboot, BMR and its restore environment are deleted. For such restores, following the restore instructions from the XML document for shadow copy component is complicated by the fact that the restore is occurring in a different environment than the client in which the data is to be restored. For UNIX clients, BMR typically boots the OS over a network, creates volumes on the client disks, mounts the volumes under the booted OS's directory structure, and restores the client files through the mount.